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One of the most vexing aspects of managing 
large programs within NASA (or any other 
high technology government programs) is 
how to allocate program funds in a way that 
is best for the program. One of the major 
reasons is that the role of cost changes 
throughout the phases of the program. An- 
other reason is that total cost is not all that 
easy to define; yet another is that funding, 
which is based on annual appropriations, is 
almost never consistent with fiscally effi- 
cient program spending rates. The net result 
is that program costs almost always escalate 
and inordinate amounts of time are spent 
controlling costs at the expense of maintain- 
ing performance or schedule. 

Many studies have been performed to try 
and understand this problem. They show 
that program costs will escalate by at least a 
factor of three, from approval to completion. 
The studies suggest a number of guidelines 
that should be followed if costs are to be kept 
down, including clear definition of require- 
ments, stable management and strong cen- 
tral control. Unfortunately, these factors are 
not always under the control of the program 
manager. 

This paper examines the question of cost, 
from the birth of a program to its conclusion, 
particularly from the point of view of large 
multi-center programs, and suggests how to 
avoid some of the traps and pitfalls. Empha- 
sis is given to cost in the systems engineer- 
ing process, but there is an inevitable 
overlap with program management. (These 
terms, systems engineering and program 
management, have never been clearly de- 
fined.) In these days of vast Federal budget 
deficits and increasing overseas competition, 
it is imperative that we get more for each 
research and development dollar. This is the 
only way we will retain our leadership in 


high technology and, in the long run, our 
way of life. 

Basic Principles 

The principles are simple. First, define very 
carefully what it is you are trying to do. 
Check everything you do against that base- 
line, even if it has to be changed, and resist 
change once the decisions have been made. 
Second, break up the program into manage- 
ably sized chunks of deliverables that can be 
measured in terms of cost, schedule and per- 
formance, and define the interfaces between 
the chunks. Third, continuously assess the 
risks to success as the program proceeds, and 
modify only as necessary. 

Requirements Traceability 

Most studies have shown that the primary 
reason for cost escalation is that not enough 
time or resources are spent in defining the 
program. It is clear that you cannot control 
what you have not or cannot define. It is dur- 
ing this period that some of the most elegant 
systems engineering should be performed, 
especially in understanding the cost of every 
requirement and its systems implication. 
Even if the definition is adequate during the 
early phases of the program, it is imperative 
that great vigilance be exercised in main- 
taining the baseline definition of the pro- 
gram and the fundamental reasons for doing 
the program. This process establishes a 
small but influential part of the program 
office, preferably within the systems engi- 
neering organization, dedicated to the trace- 
ability of requirements and to ensuring that 
a clear path exists from program rationale to 
program requirements to systems require- 
ments to systems design. Too often, once a 
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design has been established, changes are 
proposed and enacted that bear little rela- 
tionship to the original premises of the 
program. As will be discussed later in this 
paper, there are many reasons for change, 
but where possible, changes should be con- 
sidered during the formulation of the pro- 
gram and not later when the program struc- 
ture is in place and the program is in 
progress. Change is almost always costly; 
requirements traceability provides a bul- 
wark against which the program manager 
and the systems engineer can stand and 
defend. 

Baseline Cost, Schedule and 
Performance 

The three main parameters in the control 
process — cost, schedule and performance — 
are the program manager’s bread and butter. 
Again, program definition is vital and neces- 
sary from the very beginning. It may be 
argued that clear definition is not possible, 
particularly early in the program; never- 
theless, an approved, traceable baseline, al- 
though it may alter, must be known at any 
given time, and must include everything in 
the program. The “I forgots” can kill you. 

The key to success in handling these 
three parameters is to manage the balancing 
act between them. Cost, schedule and perfor- 
mance are usually dependent variables and 
at various times, one or another may assume 
greater or lesser importance. A single vari- 
able, however, should never be changed 
without knowing the impact on the other 
two. Within the NASA culture, performance 
is generally the predominant factor, and 
schedule is a distant second. Cost tends to be 
considered mostly in the context of the annu- 
al appropriation, but from the point of view 
of the program manager, all three param- 
eters must be defined and approved continu- 
ously, which is a function of the systems 
engineering process. 


Program Risk Analysis 

In recent years, especially since the Chal- 
lenger accident, program risk analysis has 
come to be used largely in the context of crew 
safety, but this is only a part of program risk. 
Basically, program risk analysis assesses the 
probability of meeting requirements as 
changes occur. A number of analytical tools 
now available can be used to understand the 
relationships between cost, performance and 
schedule. Again, a small group within the 
systems engineering organization should be 
dedicated to understanding the impact of 
any change on all three parameters. Armed 
with this information, risk can be reduced in 
many ways. Adding more money, reducing 
the performance requirements, or extending 
the schedule are most often used. A compe- 
tent systems engineer will know the rela- 
tionships between these three variables and 
the impact of any situation on the total pro- 
gram. 

The Role of Cost in Phased 
Procurement 

The most common form of procuring high 
technology capability within the Federal 
Government is known as phased procure- 
ment. The theory behind this procurement 
method is that commitment to the program 
gradually increases with time and in dis- 
crete stages. Within NASA, there are four 
standard phases; others are beginning to 
creep in as the ability to establish new pro- 
grams becomes more difficult and the dura- 
tion and cost of operations becomes a more 
significant part of total program costs. The 
role of cost is different in each of the phases. 
The phases are: 

Pre-phase A: This is a very unstruc- 
tured period that examines new ideas, 
usually without central control and mostly 
oriented toward small studies. This period 
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can last for a decade or more and produces 
the list of ideas and alternatives from which 
new programs are selected. 

Phase A: Sometimes called the feasibil- 
ity phase, this is a structured version of the 
previous phase. Usually a task force or pro- 
gram office is established, and multiple con- 
tracts will be awarded. The goal of this 
phase, which may last for several years but 
usually is limited to one or two years, is to 
decide whether a new program will be start- 
ed and what its purpose and content should 
be. This phase represents less than one per- 
cent of the total program costs. Nevertheless, 
it is largely a systems engineering effort and 
sets the stage for everything that follows. 

Phase B: Sometimes known as program 
definition, this phase is the most important 
in establishing the basic parameters of the 
program. By the time this phase is finished 
(a period of two or three years), the program 
rationale, cost, schedule, performance, man- 
agement style and the most likely technical 
solution will have been established. This 
phase usually involves multiple contracts to 
establish a variety of ideas and a competitive 
environment, should the program proceed. 
Cost is continuously assessed as a function of 
design solutions relative to basic require- 
ments. Studies indicate that from five per- 
cent to ten percent of the total program costs 
will need to be expended if control is to be 
maintained over the program during Phases 
C and D. 

Phase C/D: Originally separate phases, 
this period covers design, development, test 
and evaluation. Contracts may be open to all 
qualified bidders or only to those involved in 
the previous phase. Although competition is 
not usually open between Phases C and D, 
commitment to Phase D depends on a suc- 
cessful and acceptable design. In past pro- 
grams, two-thirds of the total program cost 
was expended during this period. The sys- 
tems engineering role has begun to shift 


toward systems specification and systems in- 
terfaces. The secret to cost control is a sound 
definition of end items and their interfaces 
with a tight hold on changes. 

Phase E: In most past programs, the op- 
erations costs were less than 20 percent of 
the total cost. This was because there was a 
definite end to a relatively short-term pro- 
gram. In recent years, particularly in the 
manned programs, the length of the oper- 
ational phase has increased significantly. In 
the case of the Shuttle, it could be conceived 
as indefinitely long. For this reason, life cy- 
cle costs should be a major consideration 
from the beginning. 

Selling the Program 

The definition of a new start within NASA 
varies by program and organization but can 
generally be said to occur at the beginning of 
Phase B. Prior to that time, the program 
manager is selling the program. The total 
expenditure of funds during the selling peri- 
od is usually far less than one percent of the 
final program costs; this is, however, when 
the basic parameters of the program are es- 
tablished. It is a time of building constitu- 
ents both inside and outside the Agency. 
Assuming that a feasible technical solution 
is available and an acceptable management 
scheme can be provided, much of the debate 
about whether a program should be approved 
centers largely around the question of cost. 
Of course, with only preliminary designs 
available, only cost estimates can be made 
and these are obtained from standard cost 
models. 

Cost Estimating 

During Phase A of the program, when the 
most rudimentary designs are available, it is 
essential that program cost estimates are 
made before the program start can be autho- 
rized. Estimates are made using cost models 
that have been developed on the basis of past 
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experience on similar programs. These 
models are among the most arcane devices 
invented by engineers, so a few words on how 
they work are appropriate. 

Past experience is captured by document- 
ing the cost of each system on the basis of 
weight. Regression analysis is performed to 
determine a straight line log relationship. 
Once the weight of the system has been esti- 
mated, the cost can be determined. This esti- 
mate is multiplied by a complexity factor to 
allow for the risk associated with the select- 
ed technology and may vary from as little as 
0.50 to 2 or more. This is repeated for each 
system, and the total becomes the baseline 
cost. This total is multiplied by a factor to 
allow for systems engineering and testing by 
the prime contractor. This is known as the 
“prime wrap” factor and is again determined 
based on all relevant past experience. All 
prime contractor estimates are added and 
then multiplied by a second factor known as 
the “nonprime wrap.” This is the cost of gov- 
ernment work. Finally, a reserve factor is 
used to allow for problems during the pro- 
gram. There are separate cost models for 
manned and unmanned programs, which are 
significantly different. In general, for the un- 
manned programs, about 40 cents of every 
dollar goes to hardware, and in the manned 
programs, about 20 cents. 

These cost models pose a great many 
problems. First, they are normalized on the 
basis of weight. Clearly this is not valid in 
all cases, particularly structure. Second, 
they do not explain why the costs are what 
they are. Factors such as management style, 
procurement strategy and test philosophy 
are not differentiated. Third, they include all 
past experience, including errors and over- 
runs. In this respect, these cost models 
assume no learning curve. As it was in the 
beginning, is now, and forever shall be! They 
must therefore be used with great caution. 
From the systems engineer’s point of view, 
these cost models can be used to assess the 
relative costs of various design solutions; on 


ah absolute basis, however, they are of little 

use. 

So far we have been able to make a tenta- 
tive estimate of the cost of the flight system. 
To this must be added the cost of new facili- 
ties, including launch, test beds, flight oper- 
ations, networks and data reduction, among 
other factors, and finally the cost of oper- 
ations. 

It is at this point that the program man- 
ager faces the first dilemma: What should be 
included in the program cost? That sounds 
like a simple question, but it is complicated 
by the fact that not all costs are under the 
control of the program manager nor is he or 
she responsible for justifying all of the asso- 
ciated appropriations. For example, launch 
costs are provided by the Office of Space 
Flight, network costs are provided by the Of- 
fice of Operations, and civil service costs are 
provided by the research and program man- 
agement fund managed by the Office of the 
Comptroller. New buildings are provided un- 
der the construction of facilities budget. In 
addition, most new program managers are 
surprised to find that a tax based on the 
number of civil servants working on the pro- 
gram varies from Center to Center, and nei- 
ther the number of people nor the level of tax 
is under the control of the program manager. 
Taxation without representation! Despite 
this dilemma, the systems engineer should 
include all of these factors in the cost esti- 
mate because the chosen design will affect 
all of them; overall program costs are as im- 
portant to the Agency as direct program 
costs. 

Program costs tend to be presented as 
only those costs that are under the control of 
the program manager. No matter how much 
this limitation is stated in presentations, it 
is assumed that it is the total program cost 
(especially when it is a popular program) 
that has the support of the Executive branch, 
the Congress and other constituencies. It is 
no wonder that the average program in- 
creases in cost by a factor of about three from 
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the time of approval to completion and that 
most program managers during this period 
are accused of everything from naivete to 
self-deception to outright lies. There is the 
added ethical question that if all costs were 
presented, the program would not be ap- 
proved! 

DEFINING THE PROGRAM 

This phase of the program, usually known as 
Phase B, will take from one to two years. The 
purpose is to take the various concepts con- 
sidered in Phase A and select a single valid 
solution. By the time Phase B is over, a clear 
set of requirements should be available with 
a complete set of functional specifications 
and a cost estimate based on preliminary de- 
sign concepts rather than on cost models. 
These are primarily produced by the systems 
engineering organization and include at 
least one preliminary design and selected 
technologies with well-understood risks as- 
sociated with those technologies. Don 
Hearth, who recently retired from NASA as 
director of the Langley Research Center, per- 
formed a study on how much this phase has 
cost for various past programs as compared 
to the success of the program in later phases. 
Success was measured as the ability to main- 
tain performance, schedule and cost as deter- 
mined at the end of Phase B. He concluded 
that the most successful programs spent 
between five percent and ten percent of the 
total program cost in Phase B. The scope was 
limited to unmanned programs, but the ra- 
tionale can reasonably be extended to man- 
ned programs. 

Apart from establishing a credible func- 
tional system specification, it is essential to 
determine the management structure, the 
procurement strategy and a baseline cost for 
the life of the program, including the cost of 
operations. Once again, the primary method 
for cost estimating is the cost model, but 
there should be sufficient detail available to 
check the model with bottom-up costs based 


on feasible design solutions. The systems 
engineer is responsible for comparing these 
two cost estimating techniques. It is unwise 
to proceed to the next phases unless some 
bottom-up cost estimating has been per- 
formed. 

Perhaps the most important product of 
this phase is a complete work breakdown 
structure. Again, this is largely the responsi- 
bility of the systems engineering organiza- 
tion. The axiom to be followed is, “You 
cannot control what you have not defined.” 

Work Breakdown Structure 

Too often a program will be approved with- 
out a well-established work breakdown 
structure (WBS) describing the whole pro- 
gram, which inevitably results in large cost 
overruns. The WBS is the basis for the pro- 
curement strategy and often for the manage- 
ment structure. Without it, program changes 
will take place after the contractors are in 
place and have to be paid. Overlaps between 
contracts, as well as missing elements and 
contract changes, are always expensive. 

The following simple rules have to be fol- 
lowed: 

1. Each element of the WBS should contain a 
deliverable that can be defined. 

2. The sum of the WBS elements must be the 
total program. (Note that a given program 
manager may not have the responsibility for 
all elements, but they should each be defined 
and allocated.) 

3. Each deliverable should be accompanied 
by a cost and a schedule. The cost should in- 
clude a reserve based on the estimated risk 
associated with that element, and the cost 
should be allocated to that element. 

As simple as these rules sound and as much 
as NASA requires contractors to adhere to 
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them, the internal track record is dismal. We 
can go a long way toward containing costs if 
discipline is established early and main- 
tained. 

One last word of caution. A WBS element 
should never be established on the basis of 
function or organization. These elements are 
not end items. Other mechanisms exist for 
identifying these elements, which in general 
could be defined as program overhead and 
not entirely the responsibility of the program 
manager. They should be recognized for 
what they are and identified, but they should 
not be included in the WBS. 

Managing the program 

We have now reached the time in the pro- 
gram when promises have been made, deals 
have been struck, and the program has been 
approved. All that remains is to deliver. A 
custom within NASA stipulates that new 
managers are installed with the belief that 
the skills required to sell a program and to 
define it are different than those required to 
run it. Certainly some changes can be ex- 
pected, but I believe that such changes are 
better if they occur sometime after a phase 
has been entered and the basic management 
structures have been established. What the 
program needs at this time is ownership of 
the concept, and changes in management 
will usually result in program changes that 
inevitably will lead to increased costs. This 
is particularly true of the systems engineer- 
ing group that has carefully balanced the 
requirements against the design and is fa- 
miliar with the “why” of a decision as well as 
the “what.” So far the total expenditure has 
been relatively low, but once the contractors 
are onboard and the manpower begins to 
build up, costs can escalate at an alarming 
rate. In a very short time, increases or de- 
creases in performance, extensions or reduc- 
tions in schedule, and decreases in annual 
funding will all increase cost. 


Design to cost. There is much talk about 
design to cost but very little action, and for 
this there are a number of reasons. Earlier, I 
mentioned that within NASA there is a ten- 
dency to order the three variables by perfor- 
mance first, schedule second, and only then 
worry about cost. So by tradition, cost tends 
to be put on the back burner. One of the rea- 
sons for this is that during the Apollo pro- 
gram, the cost function was transferred to 
the budget and program control groups. In a 
program where the technical problems were 
so difficult and the budgets were ample, this 
was understandable, but this is no longer the 
case. This situation resulted in a shift away 
from making the design engineer account- 
able for cost as well as performance and 
schedule. The second problem occurs when 
the cost is not allocated at the WBS element 
level, where it can readily be traded against 
performance and schedule and easily traced. 

I believe that cost must be allocated to the 
lowest possible level (a little scary for the 
program manager), but unless this is done, it 
will be impossible to hold the designer ac- 
countable and unlikely that overall costs 
will be held in check. The third problem is 
that in an organization that prides itself on 
technical excellence, it is very difficult not to 
make things a little better; consequently, 
there are always plenty of ideas around. The 
credo of the systems engineer should there- 
fore be: “The better is the enemy of the good.” 

Design to life cycle cost. Over the past 
decade, the operational costs of NASA pro- 
grams have steadily risen as a percentage of 
total program costs. This is largely due to the 
fact that programs have a longer life in the 
operational phase. Whereas 20 years ago 
operational costs amounted to no more than 
20 percent of costs, they are now approach- 
ing half of the NASA budget. It is time to 
place design to life cycle cost on an equal 
footing with design to cost. The dilemma is 
that a design that allows low-cost operations 
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will usually demand higher development 
costs and in turn, this means larger front- 
end program costs. It is essential that the 
systems engineer make these assessments. 
The simplest thing for a program manager to 
do is walk away from this dilemma and let 
the operations people worry about it later. 
As this is becoming an overall problem for 
the Agency, the ability to make new starts 
will depend on the ability to ensure that a 
sufficient percentage of the budget is avail- 
able for operations. Unfortunately, it is 
difficult to get enough operations people to 
participate early in the program, but I be- 
lieve it is essential. Some kind of veto power 
should be established when it comes to mak- 
ing design decisions; too many program 
managers do not feel responsible for oper- 
ations costs and perhaps, what is worse, are 
not held accountable for it. Let there be no 
doubt that operational costs are unaccepta- 
bly high. An operational concept must there- 
fore be developed early enough in the pro- 
gram to have an effect on the design process. 

Change control. Once a program is under- 
way, the program manager’s responsibility 
is controlling change, which is inevitable. 
Earlier I said that you cannot control what 
you have not defined. It is equally true that 
you cannot control changing something that 
is not defined. First know what it is! A com- 
plete WBS with allocated schedule and cost 
is, once again, the key. Change requests 
must not be limited to solving a technical 
problem. They must be accompanied by cost 
and schedule impacts and, just as important, 
life cycle cost impacts. In addition, there is 
always a rippling cost impact caused by 
change. Other WBS elements may be affect- 
ed, including items in different contracts or 
in totally different NASA codes, or line 
items. For these reasons, change must be as- 
sessed at the systems engineering level as 
well as at the WBS level. Perhaps the over- 
riding rule is that changes should be difficult 
to approve but easy to implement once the 
decision is made. 


Managing cost reserves. A qualified cost 
estimator would not let a program get start- 
ed without making provision for cost over- 
runs or reserve. The many uncertainties in a 
development program make it essential. An 
analysis of past programs allows a fairly 
accurate estimate to be made of what is a 
reasonable total amount as a percentage of 
total costs, assuming that the programs are 
similar. Determining how and when the al- 
lowance should be allocated is much more 
difficult. One school of thought says that 
reserves should be held at the highest level 
in the program and applied only to correct 
unforeseen occurrences. The problem is that 
this tends to bail out poor performers. I be- 
lieve that the reserve should be determined 
based on the perceived risk of the element 
when the WBS is formulated. The manager 
of the element should then be held responsi- 
ble for the stewardship of the reserve. In 
order for this to work, some sort of reward 
system must be established for the manager 
who does not spend the reserve. In any case, 
it would be prudent to maintain some re- 
serve at the central level for those things 
that cannot be anticipated. Just to keep the 
system honest, a very simple tracking pro- 
gram can be established to follow the expen- 
diture of the reserves at the WBS element 
level after the fact. I would like to see an in- 
depth study done on this subject. 

Traps and pitfalls 

So far we have talked about where cost fits 
into the program management and systems 
engineering processes. There are a few areas 
that may catch the program manager unpre- 
pared and a few ideas that may be used to 
make life a little easier in the future. It may 
not be possible to implement all of them, but 
it is worth a try. 

Buying in. If you are involved in the selling 
of the program, the easiest trap to fall into is 
underpricing the program. Despite stories to 
the contrary, I do not believe that this is a 


121 


READINGS IN SYSTEMS ENGINEE RING 


matter of deliberate low bidding. Although I 
once heard a distinguished gentleman say 
that we do business the old fashioned way, 
we do underbid and make up on change re- 
quests. The fact is that every program man- 
ager I have ever met was convinced that he 
or she could do it for less than the past record 
would suggest. Unfortunately, this usually 
involves changing the way we do business. I 
believe that there are less expensive ways, 
but you should tackle this one at your own 
risk and only if you have the support of the 
very top of the organization. The systems en- 
gineer must be the conscience of the program 
manager during this period. 

Design to budget. Let us assume that we 
have completed a perfect Phase B and that 
everything is in place, including the rate of 
expenditure by year. It is a virtually certain 
that two things will happen. First, with elo- 
quent rationales and spreadsheets by the 
ton, the various element managers will find 
a need to increase their funding allocation. 
One favorite argument will be that the sell- 
ers of the program, who are no longer in 
charge, will be blamed for not understanding 
the problem. In addition, Congress may add 
a requirement or two. Second, the budget 
will be cut in the Agency, at the Office of 
Management and Budget (OMB), and finally 
in Congress. At this point, the intricate pat- 
terns of dependency between performance, 
cost and schedule begin to unravel. In the 
first year, this is not devastating because 
you can always delay bringing the prime 
contractors on board. But by the time they 
arrive, the trap has been set for the most in- 
sidious form of management, design to bud- 
get. Unfortunately, a fact of life is that very 
few research and development (R&D) pro- 
grams have multi-year funding, and annual 
budgets will be less than planned. The net 
effect is that program costs will escalate, and 
enormous pressures will attempt to bring 
down the annual funding. The first remedy is 
to stretch the schedule, and the second is to 
reduce the scope of the program. You will no 


doubt find yourselves in this position, and 
you will receive a great deal of advice from 
the nonparticipants, but you should beware 
of “descoping.” A cursory examination of the 
cost models will show that in the manned 
programs, only 20 cents of every dollar go to 
hardware. (In the unmanned programs, the 
number is closer to 40 cents.) Once the man- 
agement structure is in place and the con- 
tracts have been awarded, virtually all of the 
other costs are fixed or very difficult to 
reduce. Take out all the content and the pro- 
gram cost will still be 80 percent of the 
estimate! The lesson is that if you are forced 
to remove content, you should be sure to take 
out every cent that is associated with that 
content: prime wraps, nonprime wraps, test 
beds, personnel, and, if necessary, the kitch- 
en sink. It will be difficult to find, but it will 
be worth the effort. If this were a mystery 
novel, it might well be called “The Case of 
the Missing 80 Percent.” Where does it all 
go, and why is it only 60 percent for 
unmanned programs? Much of this is valid 
and accounts for systems engineering and 
integration at all levels of the program, 
including test and evaluation, operations, 
and many other things. But it also accounts 
for duplication of test facilities, overlaps 
between assignments, management style, 
inefficiencies and a host of hidden costs asso- 
ciated with maintaining the institutions 
that are often invisible to the program man- 
ager. The systems engineer is responsible for 
ferreting out the good from the bad. It is a 
simple fact that the first one percent reduc- 
tion in these wraps (80 percent to 79 percent) 
increases the amount of hardware by five 
percent (20 percent to 21 percent)! A 20 per- 
cent improvement in the wraps (80 percent 
to 60 percent) results in a doubling of the 
hardware (20 percent to 40 percent) or cut- 
ting the program costs in half for the same 
amount of hardware! “Thar’s gold in them 
thar hills.” 

The UPN System. The NASA budget is 
prepared and submitted using a system of 


122 




COST CONSIDERATIONS IN THE SE PROCESS 


breakdowns known as the unique project 
number (UPN) system. All parts of the agen- 
cy are required to report their annual needs 
on the basis of this system, including the pro- 
gram offices. From a program point of view, 
a fatal flaw in this process is the numbering 
system, which generally describes functions 
rather than end items and is therefore not in 
consonance with the principles of a WBS sys- 
tem. It is essential that the program man- 
ager be able to trace the equivalence of the 
UPN number and its corresponding WBS 
element. This will require a joint effort 
between systems engineering and the pro- 
gram control people. Without this traceabil- 
ity matrix, the program manager will not 
know what is being asked for or where the 
money is going. Too often the UPN number 
is perceived as directly equivalent to the 
WBS element, but this is very seldom the 
case unless the WBS is not end-item orient- 
ed. (The latter happens more often than it 
should.) One way to avoid this situation is to 
make the annual budget call for the program 
using the WBS system and then translate it 
to the UPN system for the purpose of aggre- 
gating the total NASA budget. I have never 
seen this happen. 

The cost of operations. I mentioned earlier 
that the costs of operations are now about 50 
percent of the NASA budget. This is partly 
due to the increase in the operational life of a 
program and to the fact that we have not 
learned to design systems for operability. It 
has not been necessary in the past. It is also 
true that the productivity of the operations 
infrastructure has not been high on the pro- 
gram manager’s list. If we are to reduce total 
program costs, which are vital to the Agency 
and to the program, it is time to strike a new 
level of cooperation between these two nor- 
mally separate parts. The program and the 
systems engineer must assume a large part 
of the responsibility. 


THE INSTITUTION AND THE PROGRAM 

Although not directly related to the systems 
engineering process, a number of things bear 
directly on the program and have a major 
effect on the ability to perform the various 
program functions. These generally concern 
the relationship between the program and 
the institution. NASA was originally 
established using the resources of the Na- 
tional Advisory Committee for Aeronautics 
(NACA), an aeronautical research organiza- 
tion that was seldom involved in large 
development programs. The budget was rel- 
atively small, and there were few contrac- 
tors. In fact, all contracts were signed at the 
Washington office, the NACA equivalent of 
Headquarters. It quickly became apparent 
that, in addition to the research centers, a 
development center was needed. The God- 
dard Space Flight Center (GSFC) was estab- 
lished to perform this function. This was 
rapidly followed by the Lyndon B. Johnson 
Space Center (JSC) in Houston, the George 
C. Marshall Space Flight Center (MSFC) in 
Huntsville, and the Jet Propulsion Laborato- 
ry (JPL) in Pasadena. Almost immediately, 
GSFC and JPL became responsible for multi- 
ple unmanned programs, which were largely 
contained within a single Center, and JSC 
and MSFC became responsible for multi- 
center manned programs. In both cases, 
program offices were established and the 
Centers provided the resources, both person- 
nel and facilities, to support the program. 
With the exception of JPL, which was a fed- 
erally funded research and development 
center and operated outside the civil service 
system, all NASA personnel and basic facili- 
ties are funded separately from the programs 
in line items known as Research and Pro- 
gram Management (RPM) and Construction 
of Facilities (CoF). Program-specific facili- 
ties are funded by the program and these 
facilities are most often operated by support 
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contractors, also funded by the program. 
This system was established so that the pro- 
grams would be managed by government 
personnel who would rotate from program to 
program and carry their experience with 
them. This worked very well until the late 
1960s when the budget began to fall rapidly, 
and there was a significant reduction in 
NASA personnel. By the early seventies, 
both the budget and the number of personnel 
had been cut in half, but the number of 
Centers remained essentially the same. The 
cost of maintaining the institution could not 
longer be sustained by the RPM and CoF line 
items. The solution was to tax the programs 
based on the number of personnel that were 
applied to the program. Unfortunately, the 
program manager does not decide how many 
people should work on the program, which, 
by tradition, is the responsibility of the 
Center director. Neither does the program 
manager participate in determining the 
level of the tax. These decisions, again by 
tradition, are made by the comptroller. 

Maintaining the Institution 

Unless the basic system of funding personnel 
is changed, the programs will most certainly 
be responsible for funding some of the insti- 
tutional costs that are not related to the pro- 
gram; the RPM budget will never be allowed 
to grow to compensate for this. The question 
is rather how large the institution needs to 
be to support the program and how that deci- 
sion is made. I mentioned earlier that the 
WBS should represent the totality of the 
program and should always describe deliver- 
ables; this problem runs counter to that 
principle. I believe that the solution lies in 
accepting this cost for what it is, negotiating 
the level of tax with the program manager 
for the duration of the program, and taking 
it off the top each year. It may not be control- 
lable in the normal sense, but at least it is a 
known number. 

Personally, I believe that the Agency 
would be better served if the development 


centers were managed using an industrial 
funding system similar to JPL and many 
other government facilities, including the 
Navy labs. But until that happens, it will be 
necessary to find some balance between the 
institutional and program needs. 

Management Stability 

Every program will change management 
during its life cycle. The common practice in 
NASA has been to make these changes delib- 
erately between phases. It is not uncommon 
to see as many as four different managers 
during a program, including a specialist in 
closing off completed programs. The positive 
side to this is that it is possible to match the 
needs of each phase of a program to the 
special capabilities within the agency. The 
negative side is that each manager has a 
different style, each program has different 
management needs, and often these do not 
match when the change-over occurs between 
phases. One way is not always right and an- 
other always wrong, but each is different, 
and changes even in management style can, 
and usually do, increase the cost of the pro- 
gram. The secret then is to stick with a team 
as long as possible, particularly the systems 
engineering team, something that is easy to 
say and difficult to do in these times of 
declining internal expertise and increasing 
retirements. 

The Tyranny of Experience 

Too often, you will find resistance to change 
in the way things are done. “We have always 
been successful (measured by performance) 
doing it this way, and its very dangerous to 
change winning ways.” “If it ain’t broke, 
don’t fix it.” “You get no credit for an on-time 
failure.” All true and at the same time, de- 
structive to valid new ways of doing busi- 
ness, especially when it comes to introducing 
more efficient or less expensive ways. When 
the space program started, we had no 
experience and what followed was the most 
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innovative and exciting period in the history 
of high technology programs. But now we 
have all that experience, and it has become a 
burden. By all means, you should keep the 
wise heads around (they may still save you), 
but take advantage of the explosion in new 
technologies and capabilities, which allows 
for things that we could only dream of 30 
years ago. You should be careful before you 
introduce a change, but you should not dis- 
miss it out of hand. 

Does it Matter? 

We have been in the civilian space business 
for almost 40 years, and time after time we 
have shown that we can rise to any challenge 
and lead the competition, provided we have 
the resources. Time and time again the Fed- 
eral Government has provided the resources. 
We have been the envy of the world. We have 
written the book on the subject, both from a 
technical and a management sense. 

Until now, it was enough to know that we 
were the best. There was no established 
competition, most of the money was spent 
internally, and cost efficiency was second to 
performance. Some have characterized it as 
a Works Projects Administration (WPA) for 
the technologists! The problem is that in this 
era of budget deficits and trade deficits, 
there is not enough discretionary money to 
go around. Even without international com- 
petition, it would be imperative to get more 
out of our research dollars. The trouble is 
that we have learned profligate ways, as 
neither the government nor the contractors 
give rewards for cost efficiency. And while 


we were basking in this glory, the rest of the 
world has been catching up. They have been 
reading the book, and the competition, sup- 
ported by their governments, is getting good 
and fierce. 

But there is a difference; the competition 
believes that the space business is here to 
stay. I said space business, but I meant com- 
merce, and in commerce cost efficiency is 
paramount. Do we still want to stay at the 
top, or are we ready to leave it to the rest of 
the world? Are we prepared to do what is 
necessary to stay in the game? After all, it’s 
only a space program. Does it matter? You 
bet! 

Can Anything be Done? 

In this paper, I have attempted to show 
where cost fits into the space program’s engi- 
neering and management business. A combi- 
nation of things have placed cost at the 
bottom of the priority ladder except in mat- 
ters of the inexorable annual budget. There 
are many ways to improve cost efficiency, 
some of which are available to the program 
manager. In the long run, it will take a con- 
certed effort by all of us to make a difference. 
The Executive branch and Congress, togeth- 
er with industry and academia, must work 
as before, when we perceived that we were 
second. In the meantime, I hope that I have 
been able to give the budding systems engi- 
neer and program manager a few tips to do 
something about the problem of cost consid- 
erations. We can only do something about it 
if we want to! 
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